<scribe> scribe: harris
https://github.com/w3c/aria/issues/1234
james: james, do you agree that is covered in 1100?
jcraig: yea
james: perfect, I'll close this one
https://github.com/w3c/aria/issues/1232
jamesn: peter, 1.3 good?
pkra: yep
https://github.com/w3c/aria/issues/1231
jamesn: leonie has answered in the ticket
https://github.com/w3c/aria/pull/1225
<pkra> hugs joanie
matt: james, aaron and i talked about this yesterday. I don't understand the concern...We don't tell browsers where to put the value for the textbox
joanie: but they're not calculating the value for the textbox
matt: carolyn did test this and is getting the expected behavior
scott: for the textbox its the typed in text
joanie: did you do a test with
just a div?
... if we're saying "calculate a value", that to me is an
algorithm...as in do extra work. If that extra work has to be
done, it should be done in a specific place
... general text in my opinion is not being calculated
carolyn: just with a quick and dirty test, its not being exposed...I think
joanie: what are you using to test it?
carolyn: using inspect.exe (on
windows)
... it doesn't think "here" is the value of the div
Matt_King: is your concern that if we put something in here, then we must add something to aam too?
joanie: how are we going to test it?
Matt_King: we want the screen reader to use the accessibility API to get the value of the element
jcraig: it'll be doing that either way
joanie: right now, orca uses the accessibility API if it can't find out the display text for the combobox
jcraig: we're talking about the
non-editable combobox that mimics a select element
... I don't think this will conflict with the text selection
apis that would be used in a text input. Perhaps we have to do
some more word changing to make this clear
<joanie> https://chromium-review.googlesource.com/c/chromium/src/+/2142611
jcraig: the wording right now says "computed using the algorithm"
Matt_King: if we don't do that, it wouldn't quite work, would it?
jcraig: maybe "Exposed using the same method" instead?
joanie: that might make me happier
jcraig: "Exposed using the same method as a button"
jamesn: is this something we think we can get into the 1.2 aria release?
joanie: I'm in favor
jcraig: me too
... given some wordsmithing
aaron: I can land this today in chrome so people can play with it
carmacleod: is valuetext definitely the attribute we want to "steal" and use?
Matt_King: I was wondering about
that too. I was under the impression (maybe I don't understand
the APIs) that we'd want the value of this to be communicated
the same way it is for a textbox
... if the screen readers have to do work to get the
value...
carmacleod: I think the windows screen readers just get the value (html property)
jcraig: they still need to get the selected range etc.
aaron: windows has a number of
ways of getting the text. Its true that this will end up
getting exposed as the text for the object
... its designed for text that can be used with caret
... I think all we need is the plain text here
... it gives you what you need in a very simple way
james: can we work on this offline?
<Zakim> joanie, you wanted to ask if we might wish to make aria-valuetext supported on combobox
<BGaraventa> +q
jcraig: my initial point of
confusion is the fact that we're using the combobox role for 3
different type of widgets
... there's one that mimics the select and there's one that
mimics a real text field
Matt_King: I kind of agree with your point. In APG we do describe this
james: we do need to tighten up the language in the spec still
BGaraventa: how is aria-valuetext exposed on textbox?
Matt_King: its not allowed currently
BGaraventa: the issue I see is that there is such a thing as a readonly textbox
aaron: it probably makes sense to disallow valuetext on it
https://github.com/w3c/aria/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22ARIA+1.2%22
https://github.com/w3c/aria/issues/1222
MichaelC_: haven't looked at that yet
https://github.com/w3c/aria/issues/1217
carmacleod: its ready to go. just needs reviewers
https://github.com/w3c/aria/pull/1218
james: any objections to merging?
<Jon_Gunderson> +1
james: its merged
https://github.com/w3c/aria/issues/1214
https://github.com/w3c/aria/issues/1178
Matt_King: I'm fine with taking that stuff out
<jamesn> https://github.com/w3c/aria/pull/1223
Matt_King: I think I addressed Wilco's concern but now I'm a little confused by James' concern
jcraig: I'm not recommending that you keep normative language in a note
james: I think making this a note
is good without any normative language
... all the "SHOULD"s in the note would not be "SHOULD"s
anymore
Matt_King: can we say something
like "it is expected they would" or "it is expected to"?
... can we take it out of a note?
james: what if we had the conformance part as normative and the rest not? Would that help?
jcraig: this seems like a big ask for conformance checker
james: what about "conformance checkers are advised to..." in a note?
jcraig: sure, if all of the rfc statements were removed and this turned into a big note, then I'm ok with that
Matt_King: ok I'll make that
change
... maybe I should take "conformance checker" completely out of
there
james: this calls out clearly that there are a bunch of changes here too.
https://github.com/w3c/aria/issues/1164
james: if there's something that is incorrect in the current version, that needs to be in a separate issue
https://github.com/w3c/aria/issues/1151
james: there's a PR for this
https://github.com/w3c/aria/issues/1150
james: is this one covered by the same PR?
Matt_King: carolyn and james you should re-review
https://github.com/w3c/aria/issues/1143
https://github.com/w3c/aria/issues/1121
https://github.com/w3c/aria/pull/1100
jcraig: I think people are confused by tabIndex = 1. It is programmatically focusable but not tabbable
Matt_King: Focusable is the ability to be focused
<jamesn> https://github.com/w3c/aria/issues/1192
jcraig: maybe we could have
"defined focusable" as separate issue
... the other issue - we don't want to expose hidden things
just because they are focusable. We should rather expose them
if/when they are focused
Matt_King: This is weird because
right now this is actually not what happens in browsers
... maybe this is the screen reader, not the browser
... if something is aria-hidden=true AND focused, the screen
reader will announce it but it is not in the reading order
jcraig: that is a bug
<Jon_Gunderson> got to go
<pkra> got to go as well. bye everyone.
<Stefan> got to go .. sorry
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Default Present: Joanmarie_Diggs, harris, pkra, Jon_Gunderson, jamesn, MarkMccarthy, BGaraventa, StefanSchnabel, carmacleod, CurtBellew Present: Joanmarie_Diggs harris pkra Jon_Gunderson jamesn MarkMccarthy BGaraventa StefanSchnabel carmacleod CurtBellew Found Scribe: harris Inferring ScribeNick: harris WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 People with action items: WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]