Re: Seeking clarification for "undefined" as a literal value

Rich, I see. But that means "undefined" = true for aria-current, which is
counterintuitive for everyone. Right?

On Wed, Jul 19, 2017 at 5:29 PM Rich Schwerdtfeger <richschwer@gmail.com>
wrote:

> In the case of aria-current I don’t agree with as the general statement
> states: The "undefined" value,* when allowed on a state or property*, is
> an explicit indication that the state or property is not set.
>
> The undefined value is not allowed on aria-current as it is not part of
> the the enumerated list of values. That is because aria-current needs to be
> false when it is not said as it is indeed not the current item. Even if
> we were to make undefined a valid value it would need to be mapped to
> false.
>
> Rich
>
>
> Rich Schwerdtfeger
>
>
>
>
> On Jul 19, 2017, at 5:17 PM, Aaron Leventhal <aleventhal@google.com>
> wrote:
>
> Rich, one more note. I do think that the ARIA spec does have a possible
> conflict as the following general text is provided that conflicts with what
> aria-current says about an unknown value being equivalent to true:
> The "undefined" value, when allowed on a state or property, is an explicit
> indication that the state or property is not set. The value is used on
> states and properties that support tokens, and the "undefined" value is a
> string that is one of the allowed tokens. It is also used on some states
> and properties that accept true/false values, when "undefined" has a
> different meaning than "false".
>
> I would think the above general text can be thought of as applying to
> aria-current, otherwise it's a bit weird. Unless you tell me otherwise, I
> will implement aria-current="undefined" as false, which is really what
> would make the most sense for authors and users.
>
> Aaron
>
>
>
> On Wed, Jul 19, 2017 at 3:49 PM Aaron Leventhal <aleventhal@google.com>
> wrote:
>
>> Yes, thank you, I would really appreciate seeing the specs aligned.
>>
>> Do you agree that "undefined" and undefined are different for
>> aria-current? Are there any other properties that do that?
>>
>> Aaron
>>
>> On Wed, Jul 19, 2017 at 3:41 PM Rich Schwerdtfeger <richschwer@gmail.com>
>> wrote:
>>
>>> Hi Aaron,
>>>
>>> I think it always good to do that. Technically, there is nothing wrong
>>> with ARIA 1.1 but I do see where there can be confusion on the use of
>>> undefined values - although the ARIA spec. is clear. I would recommend that
>>> this be done for ARIA 1.2 given our tight schedule.
>>>
>>> That said, would you like us to make the changes, I suggested, to the
>>> core-aam so that is aligned with the spec.?
>>>
>>> At least you will know exactly what should be implemented from a user
>>> agent perspective.
>>>
>>> Rich
>>>
>>> Rich Schwerdtfeger
>>>
>>>
>>>
>>>
>>> On Jul 19, 2017, at 3:37 PM, Aaron Leventhal <aleventhal@google.com>
>>> wrote:
>>>
>>> Thank Rich, I agree with Joanie that it's weird when "undefined" and
>>> undefined (not present) mean different things, as it does in this case.
>>> That one might be so counterintuitive that most implementors would get it
>>> wrong. Most of us are not like Data on Star Trek.
>>>
>>> I also don't think it would be a bad idea to sweep through the various
>>> specs at some point and help clarify wording via non-normative changes.
>>>
>>> Aaron
>>>
>>>
>>> On Wed, Jul 19, 2017 at 2:30 PM Rich Schwerdtfeger <richschwer@gmail.com>
>>> wrote:
>>>
>>>> Hi Aaron,
>>>>
>>>> In the case of aria-current the default value is false - even when the
>>>> attribute is not set. I am looking at the list of values for aria-current
>>>> and “undefined” is not in the list. It does not take a value of “undefined.
>>>> So, if a value of “undefined” is provided (which is an invalid value as it
>>>> is not in the list) it should be set to “true” and passed to the assistive
>>>> technology with a value of “true". See Joanie’s note and the aria-current
>>>> spec.
>>>>
>>>> http://rawgit.com/w3c/aria/master/aria/aria.html#aria-current
>>>>
>>>> My previous response to you was regarding aria-checked and not
>>>> aria-current.
>>>>
>>>> What is important is that the AT is aware of a set of known values of
>>>> which “undefined” is not in the list of values for aria-current. The reason
>>>> for exposing the value of “true” to ATs was that the author made an effort
>>>> to set the value to something but it is not a value that the AT would
>>>> understand.
>>>>
>>>> Looking at the Core-AAM I can see where the confusion is. Perhaps what
>>>> the core-aam needs to say is:
>>>>
>>>>
>>>> <change>
>>>> aria-current is undefined [ARIA 1.1]
>>>> MSAA + IAccessible2 Not mapped*
>>>> <http://rawgit.com/w3c/aria/master/core-aam/core-aam.html#not_mapped>.
>>>> UIA Not mapped*
>>>> <http://rawgit.com/w3c/aria/master/core-aam/core-aam.html#not_mapped>.
>>>> ATK/AT-SPI Not mapped*
>>>> <http://rawgit.com/w3c/aria/master/core-aam/core-aam.html#not_mapped>.
>>>> AX API Not mapped*
>>>> <http://rawgit.com/w3c/aria/master/core-aam/core-aam.html#not_mapped>.
>>>> </change>
>>>> <to>
>>>>
>>>> aria-current is not present or “”:
>>>> aria-current is undefined [ARIA 1.1]
>>>> MSAA + IAccessible2  Not mapped*
>>>> <http://rawgit.com/w3c/aria/master/core-aam/core-aam.html#not_mapped>.
>>>> UIA Not mapped*
>>>> <http://rawgit.com/w3c/aria/master/core-aam/core-aam.html#not_mapped>.
>>>> ATK/AT-SPI Not mapped*
>>>> <http://rawgit.com/w3c/aria/master/core-aam/core-aam.html#not_mapped>.
>>>> AX API Not mapped*
>>>> <http://rawgit.com/w3c/aria/master/core-aam/core-aam.html#not_mapped>.
>>>> aria-current not “” and is not in the list of defined values:
>>>>
>>>>
>>>> </to>
>>>>
>>>> MSAA + IAccessible2
>>>>
>>>>    - Expose the value of aria-current in object attribute current:true.
>>>>
>>>> UIA Expose current=“true" in AriaProperties.
>>>> ATK/AT-SPI
>>>>
>>>>    - Set STATE_ACTIVE.
>>>>    - Expose the value of aria-current in object attribute
>>>>    current:"true".
>>>>
>>>> AX API AXARIACurrent: true.
>>>>
>>>>
>>>> </to>
>>>>
>>>> Is that clear enough or should I change the wording?
>>>>
>>>> Sorry for my slow response. We lost power due to tropical wave “Don”.
>>>>
>>>> Rich
>>>>
>>>>
>>>> Rich Schwerdtfeger
>>>>
>>>>
>>>>
>>>>
>>>> On Jun 30, 2017, at 10:13 AM, Aaron Leventhal <aleventhal@google.com>
>>>> wrote:
>>>>
>>>> To be clear, I've never seen the "undefined" literal used in the real
>>>> world, but it's good to get this right anyway.
>>>>
>>>> Are these correct:
>>>>
>>>> - The author can explicitly set the "undefined" literal unless the
>>>> property is required for the role.
>>>>
>>>> - Setting "undefined" is equivalent to using the default value
>>>>
>>>> - The default value itself may be "undefined" (like in aria-checked) or
>>>> not (e.g. "false" for aria-disabled). Therefore, using
>>>> "undefined"/undefined may result in undefined or a specific value depending
>>>> on the property.
>>>>
>>>> IMO the CORE-AAM could use more clarification. I don't find it covers
>>>> these cases -- at least it's not clear to me.
>>>>
>>>> Aaron
>>>>
>>>>
>>>>
>>>> On Fri, Jun 30, 2017 at 9:09 AM Joanmarie Diggs <jdiggs@igalia.com>
>>>> wrote:
>>>>
>>>>> This does have interesting implications for (at least) aria-current.
>>>>> According to the ARIA spec:
>>>>>
>>>>>     The aria-current attribute is an enumerated type. Any value not
>>>>>     included in the list of allowed values should be treated by
>>>>>     assistive technologies as if the value true had been provided. If
>>>>>     the attribute is not present or its value is an empty string, the
>>>>>     default value of false applies and the aria-current state must not
>>>>>     be exposed by user agents or assistive technologies.
>>>>>
>>>>> Thus the language is consistent with what Rich said, which means: If
>>>>> the
>>>>> value of aria-current is undefined (in the sense of a value having not
>>>>> been provided), the default of false applies, the element is not
>>>>> current, and the aria-current state must not be exposed. BUT, if the
>>>>> value of aria-current is "undefined" (a string literal), then we have a
>>>>> value not included in the list of allowed values, which should be
>>>>> treated as if aria-current were set to true (which means the
>>>>> aria-current state must be exposed by user agents).
>>>>>
>>>>> The fact that the results of undefined and "undefined" are expected to
>>>>> be the complete opposite gives me a headache.
>>>>>
>>>>> Also, looking at the Core AAM, aria-current is undefined is "not
>>>>> mapped":
>>>>>
>>>>> https://rawgit.com/w3c/aria/master/core-aam/core-aam.html#ariaCurrentUndefined
>>>>> .
>>>>> I guess Joseph thinks undefined means not defined? (To be honest,
>>>>> that's
>>>>> how my brain works too.) And I guess we need to add both flavors of
>>>>> undefined to Core AAM?
>>>>>
>>>>> --joanie
>>>>>
>>>>> On 06/29/2017 01:47 PM, Rich Schwerdtfeger wrote:
>>>>> > Aaron,
>>>>> >
>>>>> > The spec. clearly states that (see aria-checked) that “undefined” is
>>>>> the
>>>>> > (default). If nothing is specified that is what is assumed the value
>>>>> is.
>>>>> > If the author has not set aria-checked on the role that supports the
>>>>> > aria-checked states then the default is undefined. When it says
>>>>> default
>>>>> > it is very clear. Had default not been indicated then I agree there
>>>>> > would be confusion.
>>>>> >
>>>>> > So, “undefined” is a valid value. … so is leaving the attribute off
>>>>> > altogether.
>>>>> >
>>>>> > In aria 1.0 here is a test example for aria-grabbed being set to
>>>>> > “undefined” from the Candidate Recommendation test harness:
>>>>> >
>>>>> >
>>>>> https://dvcs.w3.org/hg/pfwg/raw-file/default/ARIA/1.0/tests/test-files/roles-properties-global/roles-properties-global-main-aria-grabbed-undefined.html
>>>>> >
>>>>> > This passed candidate recommendation and therefor we had working
>>>>> > implementations.
>>>>> >
>>>>> > The important thing to remember is the default value. So, programmers
>>>>> > can leave it off altogether.
>>>>> >
>>>>> > Rich
>>>>> >
>>>>> >
>>>>> > Rich Schwerdtfeger
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >> On Jun 29, 2017, at 1:32 PM, Aaron Leventhal <aleventhal@google.com
>>>>> >> <mailto:aleventhal@google.com>> wrote:
>>>>> >>
>>>>> >> As I understand ARIA, a possible value of "undefined" means the
>>>>> >> attribute is not present. If undefined is also the default, then a
>>>>> >> value of "" is equivalent. However, I would not expect a user agent
>>>>> to
>>>>> >> process the literal string "undefined" as undefined.
>>>>> >>
>>>>> >> Was there an expectation somewhere that the literal string
>>>>> "undefined"
>>>>> >> should be treated as attribute not present?
>>>>> >>
>>>>> >> I feel that the ARIA 1.1 spec could be more clear here:
>>>>> >>
>>>>> >> 'The "undefined" value, when allowed on a state or property, is an
>>>>> >> explicit indication that the state or property is not set. The value
>>>>> >> is used on states and properties that support tokens, and the
>>>>> >> "undefined" value is a string that is one of the allowed tokens. It
>>>>> is
>>>>> >> also used on some states and properties that accept true/false
>>>>> values,
>>>>> >> when "undefined" has a different meaning than "false".'
>>>>> >>
>>>>> >> Perhaps when undefined is discussed it should not be put in quotes
>>>>> --
>>>>> >> to programmers this means literal string. Mostly, CORE-AAM does
>>>>> this,
>>>>> >> but it does have one place under disallowed values that discusses
>>>>> >> "undefined" as a literal string. It does not, however, discuss the
>>>>> >> "undefined" literal as an allowed value.
>>>>> >>
>>>>> >> Can someone provide more clarity for our implementation? I'd like to
>>>>> >> see more clarity in both specs.
>>>>> >>
>>>>> >> Thank you,
>>>>> >>
>>>>> >> - Aaron
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >
>>>>>
>>>>>
>>>
>