<scribe> scribe: harris

New Issue Triage

<jamesn> https://github.com/search?l=&q=is%3Aopen+is%3Aissue+repo%3Aw3c%2Faria+created%3A%3E%3D2020-04-02+repo%3Aw3c%2Faria+repo%3Aw3c%2Faccname+repo%3Aw3c%2Fcore-aam&type=Issues

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

Combobox Value

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

1.2 Issues closeout

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