Meeting minutes
bryan: do we have any implementers in the meeting? we need them
bryan: we need an alternate computation of value
bryan: it's unclear to me and melanie what is meant by that
bryan: because value means something different depending on the element you are looking at
people say we don't necessarily
need implementers
mcking: what is the scope of it's usage
mcking: this is triggered by what I wrote in the combobox value description
mcking: I referenced part of accname....
bryan: from what I understand, everyone thinks it should be in accname, but that is confusing to me because essentially, on the surface the value is simple. when its an input it is the value. its complicated when you have something like a contenteditable field. there is no value property. if you role=textbox on contenteditable, then you need the value someone. if there is a computation, it is the innerhtml of that field. this is
maybe different if you h ave a different type of element.... if it is that simple, just the innerhtml, you are going to get different results based on the different role you are using. different computations for different elements, it can change depending on implementation
Matt_King: before we talk about the difference between elements, if the select only combobox might night be that simple, innerhtml
Matt_King: maybe we should talk about the usecases first, what do we want to cover by having a value computation referenced, where would we use it, are we aligned on that
Matt_King: if it was only one or two aria roles that need a value computation, then maybe the discussion o fwhere it belongs isn't done, if it is simple maybe it should be in the ARIA spec
Matt_King: so it seems like we should get aligned on that first
jamesn: while we are discussing what it is, lets discuss something other than value
jamesn: for select, the value is what is submitted internally, not what is displayed
jamesn: it may tie to the html values
Matt_King: it is the value that is the value in teh accessiblity tree
jamesn: may or may not be equivalent to the html value
jamesn: I think there is a potential for confusion
Matt_King: so we define a new thing, accessibleVale, accValues
bryan: how is that different from the value property in the APIs
jamesn: it will be the same for html elements, their own value calcuation
jamesn: for the aria only role=??, what is the value
bryan: it depends
bryan: I would expect it to be the innertext
bryan: but there is no defintiion
Matt_King: so how many places in the spec where we are actually missing that....
Matt_King: I have also wondered, and this might be going to far out, there are some places where if we are using accname, where we actually kind of mean value... for example, gridcells, we have never said row and column headings are name, but if you compare to excel, the content of the cell is a value, and it may or may not have a name
jamesn: I think that is another case where a value is required
bryan: there is overlap, unfortunately, if you haev something simple, like a combobox, a div role="combobox", and it includes text, like "choose the value". in theory, the accessiblename would be the content f that element. basically, how would you assign a value ot that seperately
Matt_King: the accessible value is "choose a value" and the combobox is required to have a name
bryan: name from content is supported for a combobox... or maybe it used to be?
Matt_King: it should be name from author is required
bryan: right now, because there is no value, name from content is being set as the name
<dmontalvo> Valerie: I am confused. I think that we just need to go through Matt's suggestion. Value may be calculated differently for different roles and that's how it should be
<dmontalvo> ... I guess someone should go through the spec and figure out what's best for each scenario
bryan: when I apply stuff to accname, I try to identify the points of failure. if we have a combobox, it is usually intuitively easy to understand what is the value or what is the name. a google doc as example, has rich context, you put role="textbox", then what is the value?
Matt_King: can it be multiple line rich text?
Matt_King: combobox is name from author only, it's required
Matt_King: ack spectranaut_
Matt_King: if we look at all the things that as widgets.... we could talk about those for which value doesn't apply
<spectranaut_> s/Matt_King: ack spectranaut_ //
Matt_King: we have 20 widget roles
Matt_King: and some of them for sure, value doesn't apply, like a button
Matt_King: but a checkbox -- the checkbox has a state, so not a value
Matt_King: gridcell seems like it should have a value
Matt_King: link wouldn't... menuitem...
Matt_King: progressbar would probably have an value!
jamesn: someone of them support aria-valuenow/aria-valuetext
Matt_King: slider, searchbox, separator? (supports value now) would have
Matt_King: (lists the test)
Matt_King: composite, combobox yes, grid no, listbox yes, menu no, menubar now, radiogroup... no, tablist no, tree can have a value!, but would treegrid? no,
Matt_King: if we do have a problem with value right now, what AT do with slides and others, what is the point of valuenow if valuetext is required?
jamesn: but the screenreader might want to know the difference between min and max
Matt_King: we don't have "value-mintext" and "value-maxtest"
Matt_King: seems like they are related to the concept of accValue
jamesn: at doesn't do anythign useful with min and max atm
Matt_King: it is tangentially... but the fact that valuenow is in the spec, it is an accvalue thing
Mario: if there is no special attributes to set the textbox, searchbox and combobox -- we need label -- we have both to set, not only the value, doing it by text in the box, but we also need to put the label... in other places we have by author or by content. here we need both, by content and by author
Matt_King: that is why we need to specify the content piece, what does the browser do with the content piece
Mario: we have to put computation in accname, in aria spec, we say that it is different and we need both
Matt_King: I think we need to stringify the subtree.... of the element... so in combobox.... if you have div with role combobox and inside of it it include multiple elements that were being presented visually to display the value, the text that the author wants to be the value could be distributed among multiple elements, like the label on a button. for a button, we don't just say take the inner text. essentially, the 1.2 spec says
just stringify the subtree using the same rules as accname from content for a button
Bryan: I would be in favor of it being the same value... the name being "choose country", the value should be "united states", it should compute them separately. But I don't see if it has to be a different algorithm
Matt_King: but maybe there are things that don't apply in that algorithm
Matt_King: if you are saying the value of the listbox -- you take an option, you calc the accname of the option if you are naming the option from content
Matt_King: are there things that you would include int hat option that you would include in an accname calc that you wouldn't want in the value?
Bryan: you could make an example
jamesn: why though?
Bryan: it depends on... if you have css pseudo element content... and up down arrow that appears... that will be included in the calc
Bryan: should it be included in the value.. then yes if it is displayed
Matt_King: my assumption, if we would allow it when naming the button, why not when computing value
jamesn: the accname -- "embedded control" -- what you would use as a part of that is what you would use for the value calculation
jamesn: pull it out and refer to it
Bryan: there is a list in that section that has different roles, and what to return
Matt_King: I don't know the text alternative of a selected object is
Matt_King: lets imagine you have some kind of icon button... svg, text.. we have an algorithm for calculating the accname of that button. I think that if that button were now an option in a listbox, and we want to know what would you would use for the value of the listbox... you calculate it the same way
Matt_King: that phrase, alternative text, is not defined
jamesn: it doesn't say how to calculate the value
jamesn: it is super handwavy.. and algorithm should be handwavey
Bryan: the difference between a selected option and a textbox, they aren't the same
<Zakim> jamesn, you wanted to say that secondary actions are going to complicate this
jamesn: I want to remember we have secondary actions... what we have today for a listbox, and option, in the future it might have other stuff (secondary action) that we wouldn't want to be part of the value.. .so whatever we write should work with that
Matt_King: we also need to check what is written for secondary action works with this
jamesn: there are probably ways around it, we need to be conscious of it
Matt_King: so bryan, is this much more clear now?
Matt_King: that the intent of having an accvalue algorithm?
Bryan: yeah that is clear for certain things... for an obvious thing like a button... we can identify those things.
bryan: that could be called out seperately
bryan: a lot of richtext use role="textbox"
bryan: if the algorithm populates the value for the control, the AT will be reading that instead of the content of the field -- i'm not sure but hope this doesn't happen
jamesn: my vision of this, is that "c" becomes "then return value as defined in"... then more out that part, and redefine it to make is usable in other places
jamesn: each that are different has something different in it
jamesn: no handwaviness
bryan: as far as where to put it.. a different section?
jamesn: yes, you have "text equivalent computation" calc, also, the "value computation"
Mario: for example you have a textbox, what would be the accname, and what would be the accvalue? the accname the label, and the value would be the value?
jamesn: yes
Bryan: if you are talking about a div with role="textbox"...
(scribe is getting tired)
spectranaut_: the embedded control section, more to a new section
<Adam_Page> +1 to the proposal
Bryan: I'll talk to melanie. the first step is easy, to move it out
Bryan: what I'm not clear on it how to define namefromcontent...we can work that our later
Matt_King: we might need to repeat some parts of the other algorithm.. maybe you can reference
jamesn: maybe other parts of the algorithm can be more out