Explain how values are obtained

[chlane]

In the ARIA Working Group's weekly meeting on 1/26/23, we decided that in addition to accessible names and descriptions, the accName spec should describe how to obtain an element's value if it has one. See agenda item 5 "Add explanations for how textboxes and searchboxes obtain their values" in the minutes at https://www.w3.org/2023/01/26-aria-minutes.html.

I think the spec may need to be re-named to reflect that it computes values in addition to names and descriptions.

[scottaohara]

reading the minutes, i do kinda get why it'd be removed from the ARIA spec. But while very similar, it also seems a bit odd to put this in accName. Core aam a no go for this?

[jnurthen]

Had a discussion with @spectranaut about multiple uses of the word value and thought this text (particularly item 2 in the list) shows HTML is happy to use value in multiple ways in the same sentence https://html.spec.whatwg.org/multipage/input.html#input-type-change

[MelSumner]

I'll discuss this with @accdc and will either take on the work or bring back to the group where we think this should live and why. 👍

[MelSumner]

1. This isn't really ACCNAME if it's determining the value.
2. When you're computing the content of the text field, the only thing that matters is what is going into that text field, not any of the computations or recursive elements that go into the accessible name.
3. @accdc and I agree with @scottaohara that this belongs in Core-AAM and not ACCNAME.

We made this differentiation because we realized we'd need a whole new algorithm and ACCNAME isn't really about getting the value but the name (and there's some nuance in those overloaded words).

[spectranaut]

To start, I can say confidently I do not think this calculation or definition belongs in CORE-AAM. CORE-AAM is a spec for explaining the relationship between aria and accessibility APIs, it doesn't define concepts that are used in ARIA -- instead, CORE-AAM explains how any concepts defined in ARIA are exposed in accessibility APIs. In this specific case, "value" (as in the value of a combobox) is a concept that is used in ARIA, and it's definition is not influenced by any specific accessibility API, so it belongs in ARIA (or I still think maybe accname).

I'm going to make a case for while I still think this belongs in AccName:

To start, this discussion is mostly talking about the value of text input or text input like things, like combobox, textbox or searchbox. I think most of the time it is just the value of the native html input. But as the spec says, for combobox, when the combobox does not use a native input:

the value of the combobox is represented by its descendant elements and can be determined using the same method used to compute the name of a button from its descendant content.

So already we are referencing AccName from ARIA for the definition of value. And already, in ARIA, we have an algorithm, which depends on whether the "node" in question is a native HTML input or something else. Because it references AccName and is an algorithm, I feel like it should be an extension of the AccName spec. Especially if it the definition depends on AccName and AccName changes, we don't want these two complicated things to get out of sync.

Still, I think as a first step, we need to do a little more work to lock down what the definition of "value" should actually be for these text input like things. Is the definition quoted above correct? Once we know that, maybe it will be obvious if it belongs in AccName or in ARIA. I can volunteer to look into how browser surface values for comboboxes without inputs, to start.

[accdc]

Happy to discuss this tomorrow on the call.

My concern with having this in AccName is that the recursion algorithm deals specifically with content that would and should not be returned as a value, such as the bullets or numbering within list markup, the values of aria-label, the title or alt text on images, and so on, all of which come into play with contenteditable fields for RTF fields.

Sighted users would never expect to see all of this content be returned as the value of a simple text field, but the AccName algorithm does not differentiate between the returning of simple textual content in some cases but not in others.

[spectranaut]

Discussed at the working group meeting at TPAC yesterday: https://www.w3.org/2023/09/11-aria-minutes#t03

[MelSumner]

Need to schedule a deep dive for this; @accdc and I have done some more thinking about it and need to get folks together to have a more thorough discussion about.

So first, the writeup needs to be done Then a deep-dive needs to be scheduled (when the relevant folks can attend)

I'll pull up the notes I have and try to put something coherent together for folks to pre-read so we can schedule this deep dive convo.

[spectranaut]

Proposal for Thursday Feb 29th

@cookiecrook Bryan requested you attend, can you make a deep dive on this day?

[spectranaut]

@MelSumner, I was just trying to find the appropriate issue, and I found this and https://github.com/w3c/accname/issues/200. Can we close this one a duplicate, since more recent conversation is in #200?

[MelSumner]

@spectranaut seems valid to me.